前言

狀況很奇特，奇特到我不知道該從哪里找。簡單說就是gateway裡面有mesh的話，
就會有此坑出現。

正文

先說明一下環境，Deployment A 的 VirtualService 有設定 domain , abc.com
此時進去 Deployment裡面的 pod ， 使用 curl 呼叫外部的ip，會發生404的錯誤。
e.g. curl -v 123.213.123.213 -H "Host:abc.com"
但是，如果Host不帶abc.com ，改帶任意的 domain，即可正常執行。

除錯過程

1. 使用tcpdump ，將所有的封包撈出，但發現如果 host 帶 abc.com ，沒有任何的封包進出。
   但帶任意 domain: def.com ，則會有封包進出。故開始懷疑是 sidecar的某些機制將流量導到本機，
   以至於回傳404的錯誤。

   簡易的tcpdump使用，
   詳細用法請參考連結

     針對 host 是 123.213.123.213 且 port 是 80 的封包截取，並存入demo2.pcap的檔案
     tcpdump host 123.213.123.213 and port 80 -w demo2.pcap
   

   但是從pod裡面看封包，會想哭，所以進一步要把封包的檔案放到自己的機器上，再使用wireshark看。

     將pod(api-beta-v2-primary-69797b47d6-bl6vf)，裡面的檔案 demo2.pcap 複製到本機上
     kubectl cp api-beta-v2-primary-69797b47d6-bl6vf:/app/demo2.pcap -n istio ./demo2.pcap
   

   ref. [Linux] Tcpdump 擷取封包指令範例教學

2. 查詢outbound handler

  istioctl proxy-config route api-beta-v2-primary-69797b47d6-bl6vf -n istio

終於查到了一個關鍵，在有問題domain，他match的path是另外一個virtualService(fig.1)，最後查到那個VirtualSerice ，在gateway上面多設了一組 mesh，
導致他一直在網格內繞，所以才會404。

額外補充，查詢 Inbound handler

   istioctl proxy-config listener reviews-v1-54b8794ddf-jxksn

可直接用 istioctl pc 來取代 proxy-config

ref. Istio 中的 Sidecar 注入及透明流量劫持過程詳解